Currently working through the details of these comments, mostly pretty straightforward.

While looking at your comments about renaming "spline" -> "ramp" in variable names, I did some grepping for "spline" ... there are actually a bunch more places where a rename makes sense ... not going to help if your browser was struggling with the size of this PR before, but it does make sense to address them at the same time.

The only things that came up potentially needing discussion:

• The rename of ColorSpline/FloatSpline to ColorRamp/FloatRamp: if I recall correctly, the proposal last we talked about this is that we'd go all in on compatibility shims - I'll write some tests for backwards compatibility, and as long as those work, we'll go ahead and do the rename, and change the value of the default for direction, and I guess in response to your comment, do a childAlias to rename the parameter spline to ramp as well. I suppose there is a question about how much we're actually gaining, versus just leaving the ColorSpline in place in old scenes, but if we ever want to get rid of ColorSpline, it's probably pretty worthwhile to actually do the compatibility conversions.
• The exception currently being thrown while rendering. I guess this should be a msg instead? The reason I made it an exception is that I was trying to match the old behaviour, and previously this was an exception thrown when evaluating the ShaderAssignment. Now that the representation used in the ShaderNetwork has no problems representing connections to MonotoneCubic ramps, there's no real reason to throw while evaluating the ShaderAssignment, so the problem is caught later. Oh ... I just realized that this might require a change in the Cortex code that I was hoping would get merged today. Should IECoreScene::ShaderNetworkAlgo::convertToOSLConventions never throw? Or should we be catching whenever we call it in Gaffer? Is the expectation that connections to MonotoneCubic ramps should be ignored, and emit a warning? Before, they would halt the render, but that was because evaluating the scene would fail when it got to the ShaderAssignment.

I think I've now addressed all comments ... hopefully it doesn't bog your browser down too much, since you were saying this PR was already giving you issues for some reason. If it would help, I can try to pull anything that isn't a simple rename out of the big rename commit - though I'd probably do that after squashing 59f2572 into the big rename.

Squashed last round of fixes, added changelog entries, switched dependencies to Cortex-10.7.0.0a1.

I should mention one fix that I've squashed that wasn't in the last round of fixes to review: I must not have tested the most recent version of IECoreArnoldTest, because the last round of tests of testOSLShaders were trying to compare the addresses of shaders connected to the duplicated endpoints, and that was failing - I've switched to checking that the properties of the connected shaders are correct, and that seems to be working fine now.

This should be good for interactive testing, and as far as I know, basically ready to merge.

I've removed the platform23 test. Unfortunately still got two test failures, but they seem unrelated.